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Abstract. Gist is a tool that (a) solves the qualitative analysis problem 
of turn-based probabilistic games with ^-regular objectives; and (b) syn- 
thesizes reasonable environment assumptions for synthesis of unrealizable 
specifications. Our tool provides the first and efficient implementations 
of several reduction-based techniques to solve turn-based probabilistic 
games, and uses the analysis of turn-based probabilistic games for syn- 
thesizing environment assumptions for unrealizable specifications. 



1 Introduction 

Gist (Game solver from 1ST) is a tool for (a) qualitative analysis of turn-based 
probabilistic games (2 1 fa-player games) with cj-regular objectives, and (b) com- 
puting environment assumptions for synthesis of unrealizable specifications. The 
class of 2 Y2-player games arise in several important applications related to verifi- 
cation and synthesis of reactive systems. Some key applications are: (a) synthesis 
of stochastic reactive systems; (b) verification of probabilistic systems; and (c) 
synthesis of unrealizable specifications. We believe that our tool will be useful 
for the above applications. 

272-player games. 2 1 /2-pIayer games are played on a graph by two players 
along with probabilistic transitions. We consider w-regular objectives over infi- 
nite paths specified by parity, Rabin and Streett (strong fairness) conditions that 
can express all w-regular properties such as safety, reachability, liveness, fairness, 
and most properties commonly used in verification. Given a game and an objec- 
tive, our tool determines whether the first player has a strategy to ensure that 
the objective is satisfied with probability 1, and if so, it constructs such a wit- 
ness strategy. Our tool provides the first implementation of qualitative analysis 
(probability 1 winning) of 2 b/a-player games with w-regular objectives. 

Synthesis of environment assumptions. The synthesis problem asks to con- 
struct a finite-state reactive system from an w-regular specification. In practice, 
initial specifications are often unrealizable, which means that there is no system 
that implements the specification. A common reason for unrealizability is that 
assumptions on the environment of the system are incomplete. The problem of 
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correcting an unrealizable specification ^ by computing an environment assump- 
tion <P such that the new specification $ — > is realizable was studied in [3J. 
The work [3J constructs an assumption that constrains only the environment 
and is as weak as possible. Our tool implements the algorithms of [3J. We believe 
our implementation will be useful in analysis of realizability of specifications and 
computation of assumptions for unrealizable specifications. 



2 Definitions 

We first present the basic definitions of games and objectives. 

Game graphs. A turn-based probabilistic game graph (2 1 /2-player game graph) 
G = ((S, E), (So, Sx,Sp), 5) consists of a directed graph (S, E), a partition (So, 
S\,Sp) of the finite set S of states, and a probabilistic transition function 5: 
Sp — > T>(S), where T>(S) denotes the set of probability distributions over the 
state space S. The states in So are the player-0 states, where player decides the 
successor state; the states in Si are the player-1 states, where player 1 decides 
the successor state; and the states in Sp are the probabilistic states, where the 
successor state is chosen according to the probabilistic transition function 5. We 
assume that for s € Sp and t e S, we have (s,t) £ E iff 5(s)(t) > 0. The turn- 
based deterministic game graphs (2-player game graphs) are the special case of 
the 2!/2-player game graphs with Sp = 0. 

Objectives. We consider the three canonical forms of cj-regular objectives: 
Streett and its dual Rabin objectives; and parity objectives. The Streett ob- 
jective consists of d request-response pairs { (Qi,R\), (Qi2,R2), ■ ■ ■ , (Qd,Rd) } 
where Qi denotes a request and Ri denotes the corresponding response (each 
Qi and Ri are subsets of the state space). The objective requires that if a re- 
quest Qi happens infinitely often, then the corresponding response must happen 
infinitely often. The Rabin objective is its dual. The parity (or Rabin-chain ob- 
jective) is the special case of Streett objectives when the set of request-responses 
Qi C i?i C Q2 C i?2 C Q3 C ■ • • C Qd C Rd form a chain. 

Qualitative analysis. The qualitative analysis for 2!/2-player games is as fol- 
lows: the input is a 2 1 /2-player game graph, and an objective <P (Streett, Ra- 
bin or parity objective), and the output is the set of states such that player 
can ensure # with probability 1. For detailed description of game graphs, plays, 
strategies, objectives and notion of winning see Q]. We focus on qualitative anal- 
ysis because: a) In applications like synthesis the relevant analysis is qualitative 
analysis: the goal is to synthesize a system that behaves correctly with proba- 
bility 1; (b) Qualitative analysis for probabilistic games is independent of the 
precise probabilities, and thus robust with imprecision in the exact probabilities 
(hence resilient to probabilistic modeling errors). The qualitative analysis can 
be done with discrete graph theoretic algorithms. Thus qualitative analysis is 
more robust and efficient, and our tools implements these efficient algorithms. 



3 Tool Implementation 



Our tool presents a solution of the following two problems. 
Qualitative analysis of 2 1/2-player games. Our tool presents the first imple- 
mentation for the qualitative analysis of 2 LV player games with Streett, Rabin 
and parity objectives. We have implemented the linear-time reduction for qual- 
itative analysis of 2 1 /2-player Rabin and Streett games to 2-player Rabin and 
Streett games of [2] , and the linear-time reduction for 2 LVplayer parity games to 
2-player parity games of [I] . The 2-player Rabin and Streett games are solved by 
reducing them to the 2-player parity games using the LAR (latest appearance 
records) construction [5]. The 2-player parity games are solved using the tool 
PGSolver [5J. 

Environment assumptions for synthesis. Our tool implements a two-step 
algorithm for computing the environment assumptions as presented in [3]. The 
algorithm operates on the game graph that is used to answer the realizability 
question. First, a safety assumption that removes a minimal set of environment 
edges from the graph is computed. Second, a fairness assumption that puts 
fairness conditions on some of the remaining environment edges is computed. The 
problem of finding a minimal set of fair edges is computationally hard [3] , and a 
reduction to 2 i/2-player games was presented in [3] to compute a locally minimal 
fairness assumption. The details of the implementation are as follows: given an 
LTL formula 0, the conversion to an equivalent deterministic parity automaton is 
achieved through GOAL [3]. Our tool then converts the parity automaton into 
a 2-player parity game by splitting the states and transitions based on input 
and output symbols. Our tool then computes the safety assumption by solving 
a safety model-checking problem. The computation of the fairness assumption 
is achieved in the following steps: 

— Convert the parity game with fairness assumption into a 2 ^-player game. 

— Solve the 2 !/2-player game (using our tool) to check whether the assumption 
is sufficient (if so, go to the previous step with a weaker fairness assumption). 

The synthesized system is obtained from a witness strategy of the parity game. 
The flow is illustrated in Figure [TJ 
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Fig. 1. An example illustrating the flow of the tool 
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Fig. 2. An example that illustrates the tool flow 



We illustrate the working of our tool on a simple example shown in Figure [2] 
Consider an LTL formula <P = GFgrant AG(cancel — > ^grant), where G and F 
denote globally and eventually, respectively. The propositions grant and cancel 
are abbreviated as g and c, respectively. From <P our tool obtains a deterministic 
parity automaton (Figure 2(a) I that accepts exactly the words that satisfies <P. 
The parity automaton is then converted into a parity game. In Figure [2(b)] □ 
represents player states and O represents player 1 states. It can be shown 
that in this game no safety assumption required. We illustrate how to compute 
a locally minimal fairness assumption. Given an fairness assumption on edges, 
our tool reduces the game with the assumption to a 2 ^-player parity game 
(see details in [3]). If the initial state in the 2 1 / / 2-player game is in winning 



with probability 1 for player 0, then the assumption is sufficient. Figure 2(c) 



illustrates the 2 i/^-player game obtained with the fairness assumption on the 
edge (0, 4). The Q state is the probabilistic state with uniform distribution over 
its successors. The assumption on this edge is the minimal fairness assumption for 
the example. Our tool then converts this game back into an automaton to obtain 
the environment assumption as an automaton(Figure 2(d)). This assumption is 
equivalent to the formula G(-i(cancel A grant)) => G-F(^cancel). From a 
witness strategy in Figure 2(c) our tool obtains the system that implements the 
specification with the assumption (Figure 2(e) I. 



Performance of Gist. Our implementation of reduction of 2 ^-player games 
to 2-player games is linear time and efficient, and the computationally expensive 
step is solving 2-player games. For qualitative analysis of 2 1 /2-player games, 
Gist can handle game graphs of size that can be typically handled by tools 
solving 2-player games. Typical run-times for qualitative analysis of 2 l /2-player 
parity games of various sizes are summarized in Table [3J The games used were 
generated using the benchmark tools of PGSolver and then converting one-tenth 
of the states into probabilistic states. 



States 


Edges 


Runtime (sec.) 






Avg. 


Best 


Worst 


1000 


5000 


1.17 


0.63 


1.59 


5000 


25000 


15.94 


11.10 


19.46 


10000 


50000 


51.43 


39.38 


62.61 


20000 


100000 


282.24 


267.40 


310.11 


50000 


250000 


2513.18 


2063.40 


2711.23 



Table 1. Runtimes for solving 2!/2-player parity games 



In the case of synthesis of environment assumptions, the expensive step is the 
reduction of LTL formula to deterministic parity automata. Our tool can handle 
formulas that are handled by classical tools for translation of LTL formula to 
deterministic parity automata. 

Other features of Gist. Our tool is compatible with several other game solving 
and synthesis tools: Gist is compatible with PGSolver and GOAL. Our tool 
provides a graphical interface to describe games and automata, and thus can 
also be used as a front-end to PGSolver to graphically describe games. 
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4 Appendix: Details of the Tool 



Gist is available for download at |http : //pub . ist . ac . at /gist for Unix-based 
architectures. All the libraries that Gist uses are packaged along with it. 

4.1 Dependencies and Architecture 

Language, tools and installation. Gist is written in Scala and it uses several 
other tools. For the graphical interface to draw game graphs and automata it 
uses the JUNG library 7 for graph layout algorithms. For translation of an LTL 
formula to a deterministic parity automata it uses GOAL [5]. The solution of 
2-player parity games is achieved by using PGSolver jfr. For compilation and 
installation: (a) an installation of the Scala compiler and runtime environment 
is required; (b) the PGSolver build process requires an OCaml compiler to be 
installed; and (c) GOAL and JUNG require a Java runtime environment to be 
installed. 

Source code. The source code of Gist is composed mainly of five modules: 

1. Module newgames mainly consists of the classes for probabilistic w-regular 
games, i.e. games with Biichi, coBiichi, Rabin, Streett and parity objectives. 
Each of these classes contains routines for the reduction of the 2 1 /2-player 
version to the 2-player version which preserves the probability 1 winning 
region of Player 1. Each of these classes also returns a witness strategy for 
the player as required. 

2. Module specification consists of classes implementing the specifications 
for the synthesis problem, i.e. LTL formulae, Biichi automata and parity 
automata. The class for LTL formulae contains a routine to convert LTL 
formulae into an equivalent nondeterministic Biichi automata and the class 
for Biichi automata has a routine for converting it into a deterministic parity 
automaton. The parity automata class can generate the synthesis game (by 
splitting transitions) for the automaton as described in [3J. 

3. Module synthesis contains the classes relevant to the process of synthesis. 
The class for synthesis games contains routines (a) to compute transducers 
implementing the specification; (b) to compute minimal safety assumption 
and locally minimal fairness assumption in case of an unrealizable specifica- 
tion; (c) to check whether user-specified assumptions are sufficient to make 
the specification realizable; and (d) to get the assumptions as a Streett au- 
tomaton. 

4. Modules gui and cui contain classes for graphical and text based user in- 
terfaces. Most of the functionality in the cui module is contained in the 
Console class, which interprets a command line. The gui module contains 
forms and windows to display various automata and games; and provide an 
interface for the various operations on them. 

5. Module basic contains the definitions which are needed by all other packages, 
namely, the classes for alphabet, symbols and generic automata. 



In addition to these, there are other routines to parse and write automata and 
game graphs in files in a format that can be used with GOAL. 

4.2 User Manual 

In this section we describe the usage of the graphical and text-based interface 
of the tool. 

Format of files. The file format used by the tool is based on the format used 
by GOAL. The format for games and automata structures is presented below: 

<structure label-on="transition" type= ["game" I "f a"] > 
<alphabet type="propositional"> 

<prop type= [ " input " I " output " ] >TEXT</prop> 

</alphabet> 
<stateSet> 

<state sid="NUMERIC"> 

[<player> [0 1 1 1 -1] </player>] 
[<label>TEXT</label>] 
</state> 

</stateSet> 
<transitionSet> 

transition t id= " NUMERIC " > 

<from>NUMERIC (State ID)</from> 
<to>NUMERIC (State ID)</to> 
<read>TEXT (Symbol) </read> 
</transition> 

</transitionSet> 
<initialStateSet> 

<stateID>NUMERIC</stateID> 
</initialStateSet> 

<acc type=" [buchi I parity I rabin I streett] "> 

<accSet> °/0ny one set for Buchi acceptance condition. 
<stateID>NUMERIC (State ID) </stateID> 

</accSet> 

<accSet> "/Multiple sets for Parity acceptance condition. 
°/ 0ne for each priority 
<stateID>NUMERIC (State ID) </stateID> 

</accSet> 

<accSet> "/Multiple sets for Rabin and Streett acceptance conditions. 
"/Different format from the other conditions. 

<E> 



<stateID>NUMERIC (State ID) </stateID> 



</E> 
<F> 



<stateID>NUMERIC (State ID) </stateID> 



</F> 



</accSet> 
</acc> 
</structure> 

Graphical Interface. The graphical interface for Gist consists of a window for 
each kind of game graph, automata, and formula the tool handles. When Gist is 
invoked, a window is shown with buttons for each kind. A window for a specific 
kind contains buttons that represent relevant actions that can be performed. 
There are also generic options such as saving and loading. 

For automata and game graphs, the window contains an area in which the 
graph is laid out visually. The layout can be changed by dragging the vertices and 
the edges of the graph. Gist uses the layout algorithms of JUNG to automati- 
cally layout the graph. The layout algorithms can be chosen by right-clicking on 
the window and selecting Layout from a pop-up menu that appears. Also, sets 
of vertices or edges can be highlighted for other operations (such as finding suf- 
ficiency of assumptions containing these edges) by choosing Highlight Mode 
on the pop-up menu. 

The tool also includes interfaces for building automata and games graphically. 
In these windows, one can insert states or edges into a structure by selecting the 
appropriate mode from the pop-up menu. When an edge is created, the user can 
label the edge appropriately. The alphabet for the symbols (for labeling edges) 
must be set before the edges are created. States and edges can also be deleted 
using the Delete mode. 

Text-based Interface. The text-based interface for Gist is an interactive 
prompt. The user can define and use variable for any object. Variables need 
not be declared before use. All variable names need to begin with a $. The 
syntax for the statements is defined below. 

Variable := $ [a-zA-ZO-9] * 

Statement := Variable — Prints the value of the variable 



Expression := Object Action 

Object := "LTL" I "BuchiAutomaton" I "ParityAutomaton" 

I "SynthesisGame" I "StreettAutomaton" I "ParityGame" 
I "RabinGame" I "StreettGame" 

Action := readFile ... I writeFile ... I help I ... 



I Variable = Variable 
I Variable = Expression 



-Assignment 
-Assignment 



The "action" as seen in the above syntax definition varies depending upon the 
object. The help action for any object displays all the other actions available 
for this object along with an explanation. 

All objects which represent games have the following actions: winningRe- 
gion, cooperativeWinningRegion, and toDeterministicGame. The action 
winningRegion takes an argument, either or 1 (for a player), and computes 
the set of states from which the player wins with probability 1. The action co- 
operativeWinningRegion is invoked only for 2-player games, and it computes 
the set of states such that there is a path to satisfy the objective of player 0. 
The action toDeterministicGame is invoked on 2 1 /2-player games and it re- 
turns a 2-player game in which probability 1 winning of player is preserved. In 
addition, the action winningStrategy computes the winning strategy of each 
player in 2-player games, and the probability 1 winning strategy in 2 Y2-player 
games. 

The objects for Biichi automata have an action toParityAutomaton to 
convert it into equivalent deterministic parity automata. Similarly, the objects 
for LTL formulae and parity automata have actions to convert them into non- 
deterministic Biichi automata and Synthesis games respectively. The objects for 
Synthesis games have actions related to synthesis and computation of environ- 
ment assumptions. 

The text-based interface for Gist is also available online at 
http://pub.ist.ac.at/gist. Figure [3] shows the screenshot for the text- 
interface with input and output for Example 1 (described in the following 
subsection). Figure Q] shows the screenshot of the web interface for a similar 
example. 

4.3 Examples to Illustrate the Usage of Gist 

In this section, we present two examples to illustrate the usage of Gist. We 
have chosen small examples for the simplicity of the presentation to illustrate the 
usage of Gist. These examples demonstrate the usage of Gist for computation of 
environment assumptions for synthesis and uses solution of 2 1 / / 2-player games. In 
these examples, we compute the assumptions for two unrealizable specifications 
given in LTL. Both the specifications are about request-response systems and 
are chosen to illustrate safety and fairness assumptions respectively. 

Example 1. Consider a request- response system in which there are two inputs, 
request and cancel, and one output grant. Now, consider the specification 
G(request grant) A G(cancel — > -igrant). This specification is unrealiz- 
able: any input in which both request and cancel are set at the same time 
does not have an output which satisfies the specification. We can compute an 
environment assumption for this specification using Gist. Intuitively, we would 
want an assumption that says request and cancel must not be set at the same 
time provided the specification was not already violated earlier. We show that 
the assumption can be computed automatically by Gist. 

To compute the assumption using Gist, we select LTL formula from the main 
window of options and then enter the formula above, specifying the inputs and 



3 GIST demo 
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GIST> $f onnula = LTL read 
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Enter inputslspace separated): r c 
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Fig. 3. Example to illustrate the text-based interface 



outputs. This formula is then converted into a nondeterministic Biichi automaton 
and then to a deterministic parity automaton, and finally to a synthesis game. In 
this game, we attempt to compute the safety assumption. The safety assumption 
is highlighted (green arrows in a box; (0,4) and (2,7)) as shown in Figure [5] As 
shown in Figure EJ the safety assumption includes all the edges where request 
and cancel are set at the same time. But, if there has been an instance of a 
request not being granted already, then there is no restriction on the inputs. 
This is the same assumption as was expected intuitively. Now, we can obtain 
a synthesis game where the safety assumption is enforced. In this new game, if 
the fairness assumption is computed the output shows no fairness assumption 
is necessary. A transducer that implements the modified specification can be 
obtained from the solution of this game. 

Example 2. Consider the request- response system as in Example 1. But, with 
the specification (GFgrant) A G(cancel — > -igrant). This specification says 
that we should have infinitely many grants and that at every step, if cancel 
is set, then there should be no grant at that step. This specification is also 
unrealizable as any input where the cancel is always set has no acceptable 
output. We can see that if cancel is not set always after a point, then the 
specification becomes realizable. This condition can be computed using Gist 
following the same steps as in the above example: first the tool finds that no 
safety assumption is necessary, and then it computes the fairness assumption in 
the synthesis game. The fairness assumption is computed internally by reduction 
to 2 1 / / 2-player games. The fairness assumption is highlighted (by green arrow 
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Output: 

GIST> $f annuls = LTL read 

Enter formula: G[r --> g) A G(g --> X~g) 

Enter inputsfspaee separated); r 

Enter outputs [space separated): g 

CIS I > SBA - LIL toBucniAutcmaton Jfonrula 

CIST> SPA - DLchiAutonator toPa"ityALtoma:on $GA 

GTST> Sgaup = Pa r . * yA.j I prrin ton I oSyri Hts i sGamp $PA 

C1SI> SyntiesisGane computeSa"etyAssi.irpt:on $game 

List (C. 7)) 

GIST> $safeganie = Synthesis Game enf orc^Saf ^ty;Assjjiiiptiori ^qam* 
GIST> $safegame 

Alphabet : INPUTS Listfr) OLTTPUTS: List(g) 

Number of States : 13 
Transitions : 

[10,2, -g), [10,1, g), (3,10, r)» (9,3, ~g), [9,1, g), (3,9, ~r), 
[8,2, True), [2,8, True), [7,2, True), (7,2, g), [1,11, r) , (6,3, ~g), 
[6,2, g), [1,6, -r), [5,2, ~g), [5,1, g), [G,5, r), [4,3, ~g), [4,1, 
g), (0,4, -r), (11,12, True], (12,11, True), 
Priorities : [0-1] 

Priority G i ArraytG, 1, 3, 4. 5, 6, 7, 9, 1G, 11, 12) 

Priority 1 : Array[2, 8) 
GIST s- 



|synthesisGame enforceSafetyAssumption $safegame 



Fig. 4. Gist web interface 
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Fig. 5. Example 1. The safety assumption is highlighted 



in a box; (0,4)) in the screenshot Figure [5] The computed assumption can be 
interpreted as follows: the highlighted edge must be taken infinitely often if 
the source vertex of the edge is visited infinitely often. Translating this into 
propositions, it means that at any step, cancel cannot be set forever in the 
future. 
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Fig. 6. Example 2. The fairness assumption is highlighted 



